I think this change could be orthogonal to #939. It enables msbuild to behave like VS does, in the presence of sln based project dependencies. Without this change msbuild injects an extra ProjectReference, whereas VS does not. This makes building in VS different from building in the command line. Right now this difference in behaviour exposes #939. In the future it might have other random side effects.

In addition, the right user gesture for #939 is to explicitly declare a project reference inside the csproj file, whereas this PR handles the case when the user wants (for some unknown reason) a sln based dependency.

On the other hand, we could consider sln based dependencies obsolete, and in that sense encourage users to mark the dependency accordingly in the csproj instead. From this point of view it makes sense to not take this PR, and guide users to the correct solution when they use sln based dependencies and get a build error from the command line.

When MSBuild is generating the from-solution-dependencies ProjectReferences, we mark them with the same metadata that a user would use for an explicit reference.

This knob is orthogonal to correct ProjectReference behavior, but I'm concerned about changing the in-solution build experience only for SDK projects. That seems like something that'd come back to bite us in the future.